A virtual machine system permits a physical machine to be partitioned, such that the underlying hardware of the machine appears as one or more independently operating virtual machines (VMs). A Virtual Machine Monitor (VMM) runs on a computer and presents to other software an abstraction of one or more VMs. Each VM may function as a self-contained platform, running its own operating system (OS) and/or application software. Software executing within a VM is collectively referred to as guest software.
The guest software expects to operate as if it were running on a dedicated computer rather than a VM. That is, the guest software expects to control various events and to have access to hardware resources on the computer (e.g., physical machine). The hardware resources of the physical machine may include one or more processors, resources resident on the processor(s) (e.g., control registers, caches, and others), memory (and structures residing in memory, e.g., descriptor tables), and other resources (e.g., input-output devices) that reside in the physical machine. The events may include interrupts, exceptions, platform events (e.g., initialization (INIT) or system management interrupts (SMIs)), and the like.
The VMM may swap guest software state in and out of the processor(s), devices, memory and the registers of the physical machine as needed. The processor(s) may swap some state in and out during transitions between a VM and the VMM. The VMM may enhance performance of a VM by permitting direct access to the underlying physical machine in some situations. This may be especially appropriate when an operation is being performed in non-privileged mode in the guest software, which limits access to the physical machine or when operations will not make use of hardware resources in the physical machine to which the VMM wishes to retain control. The VMM is considered the host of the VMs.
The VMM regains control whenever a guest operation may affect the correct execution of the VMM or any of the non-executing VMs. Usually, the VMM examines such operations, determining if a problem exists before permitting the operation to proceed to the underlying physical machine or emulating the operation on behalf of a guest. For example, the VMM may need to regain control when the guest accesses I/O devices, when it attempts to change machine configuration (e.g., by changing control register values), when it attempts to access certain regions of memory, and the like.
Existing physical machines that support VM operation control the execution environment of a VM using a structure herein referred to as a Virtual Machine Control Structure (VMCS). The VMCS is stored in a region of memory and contains, for example, state of the guest, state of the VMM, and control information indicating under which conditions the VMM wishes to regain control during guest execution. The one or more processors in the physical machine read information from the VMCS to determine the execution environment of the VM and VMM, and to constrain the behavior of the guest software appropriately.
The processor(s) of the physical machine will load and store machine state when a transition into (i.e., entry) or out (i.e., exit) of a VM occurs. Conventional architectures perform a predetermined set of state loading and storing, as defined in processor specifications in a manner similar to other system structures, instruction encodings and machine behaviors. The VMM is coded directly to these specifications. This structuring limits the implementation flexibility of the VMM.
Therefore, there is a need for improved implementations of techniques for entering and exiting VMs. These implementations and techniques should permit better management and control of VM operations.